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It should be noted that the Terminal IMP will be unable to 
directly implement the currently-proposed mailbox protocol for 


the following reasons: 


a) The Terminal IMP is completely incapable of storing 
incoming messages for later printing or display. 


b) The Terminal IMP is not expected to be able to perform 
as the "server" portion of any connection. 


c) The Terminal IMP cannot provide programs for the 
processing of a variety of types of input streams. 
It currently supports the TELNET protocol, and is 
expected to support at least one mode of Data 


Transfer Protocol in the future. 


It is _not_ likely 


to support the File Transfer Protocol. Furthermore, 
when using the Data Transfer Protocol it will not 
perform any transformations on the data stream 
(e.g., interpretation of line printer form-control 
"characters," translation from one character set to 


another, etc.). 


It will be up to the "other end" 


of the connection to set up and decode messages based 


on the terminal type. 


Although these limitations preclude Terminal IMPs from 
participating in the currently-proposed mailbox protocol, this 
should not be considered an objection to implementation of the 
protocol, provided that Terminal IMP installations will be 
guaranteed the right to "rent" mailboxes at some larger Host 


site [the NIC is probably a good candidate]. 


With this capability, 


a message destined for a Terminal IMP user would be shipped to the 
site of the "rented" mailbox according to protocol and stored 
there. A terminal IMP user could then periodically log in to that 
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site (under TELNET protocol) and examine the contents of the 

mailbox; since the "examination" would be carried out over a 

TELNET connection the Host containing the mailbox would _automatically_ 
perform the necessary transformation of the data before transmitting 

it to the Terminal IMP. 


A technically unattractive alternative to this scheme would 
be to _require_ each Terminal IMP site to have a printer dedicated 
to the mailbox function. If the mail were then transferred in 
TELNET format, we could probably provide a socket connected to 
the dedicated printer for receipt of mail. Obviously, if this 
scheme were chosen, a Terminal IMP could accept mail from only 
one sender at a time, and the transmission rate would be limited 
to the speed of the printer. Furthermore, a single central 
mailbox printer is likely to provide poor service to Terminal 
IMPs with widely scattered terminals (e.g., dial-in terminals 
distributed over an area with a 10-mile radius). 


We feel that, in addition to other arguments, it would be 
more cost-effective to provide storage for rented mailboxes at 
one site than to provide a _special_ mailbox printer at each 
Terminal IMP site. 
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